|
Labo : MTU par Philippe Bovier Introduction sur le MTU MTU (Maximal Transmission Unit) est la plus grande taille possible d'un paquet de données, envoyée en une seule fois à travers le réseau Internet. Ce paquet transitera de la source désirée à votre FAI (Fournisseur d'Accès Internet) jusqu'à vous à travers de nombreux chemins, en passant par X routeurs, X passerelles et X protocoles réseaux. Le MTU maximum théorique est de 1500 (défini pour les plates-formes Windows). Cette taille maximale théorique est idéale pour les réseaux TCP (local), l'ADSL ou le câble mais pas pour un modem RTC (ancien protocole). Un MTU=1500 ou approchant n'est pas grave en terme de réception avec l'ADSL. L'ADSL étant un protocole fiable et récent, un MTU non optimisé n'entraînerait pas une grande différence en vitesse de réception des données (vu la vitesse de travail de l'ADSL). Principalement en RTC, si vous avez des messages d'erreurs ou des temps trop long lors d'accès à certains sites ou des chutes de débit lors de téléchargements FTP, il vous faut vérifier et/ou corriger cette valeur car c'est le signe d'une fragmentation des paquets de données. Si votre MTU est trop grand, votre FAI scindera le paquet en autant de fois que nécessaire ce qui vous donnera une réception lente voire pas de réception du tout. Description et valeurs standards Chaque paquet se compose de données, appelé MSS (Maximum Segment Size) auquel s'ajoute un en-tête TCP et une en-tête IP. MTU = MSS + en-tête TCP/IP. MSS = MTU - 40 (40 = en-tête de 20 bytes TCP + en-tête de 20 bytes IP).
Exemples concrets et théoriques 1. Premier exemple Cas de transfert avec 1500000 bytes de données à travers une ligne T1. Note : le débit d'une ligne T1 est de 1544000 bits/sec. 1.1 Taille des paquets et temps d'attente Temps d'attente en ms (milli-secondes) = [(MSS+HEADER) x 8 bits] / 1544000 bits/sec. En utilisant différentes valeurs de MTU, nous pouvons calculer le temps d'attente de traversée d'un paquet dans le réseau T1. MTU = 1500 : (1460+40) x 8 / 1544000 = 7.772 ms. MTU = 576 : (536+40) x 8 / 1544000 = 2.924 ms. Si, par exemple, il faut 10 paquets pour envoyer et recevoir ces données, il faudra donc : MTU = 1500 : 77.72 ms. MTU = 576 : 29.24 ms. Un MTU plus petit transmet donc plus vite les données. 1.2 Taille et nombre de paquets Reprenons le même exemple que précédemment mais avec juste 1 Mb. 1 Mb = 1024 Kb = 1048576 bytes. MTU = 1500 : (1460+40) x 8 / 1544000 = 7.772 ms. 1 Mb / MSS = 1048576 bytes / 1460 = 719 paquets pour 1 Mbytes. Pour transférer 1 Mb : 719 paquets x 7.772 ms = 5588068 ms donc 5.588 secondes. MTU = 576 : (536+40) x 8 / 1544000 = 2.924 ms. 1 Mb / MSS = 1048576 bytes / 536 = 1957 paquets pour 1 Mb. Pour transférer 1 Mb : 1957 paquets x 2.924 ms = 3722.22 ms donc 3.722 secondes. Un MTU plus petit transmet plus de paquets et toujours plus vite. 1.3 Taille des entêtes TCP/IP MTU = 1500 : (nombre de paquets x header) = 719 x 40 = 28760 bytes. MTU = 576 : (nombre de paquets x header) = 1957 x 40 = 78280 bytes. La quantité de données des en-têtes est supérieure avec 576 (78280 bytes). Les 49550 bytes supplémentaires en MTU = 576 ne représentent qu'une infime fraction du total des données (ici avec un exemple de 1048576 bytes). 1.4 En résumé (pour l'exemple de la ligne T1) Un petit MTU transmet plus de paquets et plus vite qu'un gros MTU. La différence de taille des en-têtes transmises est infime comparé à la taille des données. On peut donc juger par ces calculs qu'il est impérativement important d'avoir un bon MTU et pas obligatoirement le plus grand possible. La valeur du MTU choisie dépendra du matériel, du FAI et du type de connexion utilisé (RTC ou ADSL). La différence de temps d'attente entre un MTU = 1500 et un MTU = 576 est visible avec l'exemple précédent avec une ligne T1 rapide. Cette différence sera encore plus importante avec une simple connexion par modem RTC (RTC étant un ancien protocole moins fiable et régulier en émission et réception que l'ADSL). 2. Second exemple Cas avec un Amiga et MiamiDX avec modem RTC 56k. Une connexion par défaut, faite par MiamInit, règle le MTU par défaut à 552. Cette valeur par défaut ne peut être qu'une base de départ qu'il vous faut vérifier de chez vous. L'article considère que le lecteur connaît dans son programme TCP/IP où se situe la valeur MTU à modifier selon ses besoins. Les exemples suivants existent uniquement avec mon Amiga et son matériel (modem, carte série,...). Les résultats que vous allez obtenir seront sûrement différents mais au moins ils auront été contrôlés grâce à la suite de cet article. 2.1 Programmes complémentaires (exemples RTC ou ADSL) Il est possible graphiquement de vérifier vos transferts Internet avec votre Amiga de 2 façons bien plus pratiques car visuelles : Miamigraph : Disponible sur Aminet. Avec son appel lors de la connexion : MiamiDX -> Evémements -> Démarrer. MiamiGraph PERIOD=50 DIVISIONS=1 BCOL=000000 GCOL=00FF00 DCOL=FF0000 BORDERLESS INTERFACE=ppp0 (ppp0 à changer selon le nom de votre connexion). GelBesPanel : Chargement à partir de MiamiDX -> GUI -> Réglages panneaux de contrôles. Disponible sur gelbespanel.amigazeux.net.
2.2 MiamiPing avec valeur 296, 492, 568, 1492 et modem 56k RTC à 45333 Pour mesurer le temps de réponse d'un paquet envoyé vers un endroit, il nous faut utiliser l'utilitaire MiamiPing fourni dans l'archive de MiamiDX. Cet utilitaire possède la ligne de commande suivante : usage: MiamiPing [-Rdfnqrv] [-c count] [-i wait] [-l preload] [-p pattern] [-s packetsize] host -f = rapide -c 10 = nombre d'essais -s 492 = MTU 294.217.300.20 = club-internet.fr (la valeur pour cet article est un exemple). La valeur 294.217.300.20 se trouve dans : Miami -> base de données -> serveurs DNS. 296 rapide avec -f : MiamiPing -f -c 10 -s 296 294.217.300.20 PING 294.217.300.20 (294.217.300.20): 296 data bytes 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 182.026/185.238/190.497 ms MiamiPing -f -c 10 -s 296 294.217.300.20 PING 294.217.300.20 (294.217.300.20): 296 data bytes 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 180.574/184.861/189.658 ms MiamiPing -f -c 10 -s 296 294.217.300.20 PING 294.217.300.20 (294.217.300.20): 296 data bytes 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 180.959/185.057/190.57 ms Miami/MiamiPing -f -c 10 -s 296 294.217.300.20 PING 294.217.300.20 (294.217.300.20): 296 data bytes 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 177.682/187.284/198.666 ms 492 rapide avec -f : MiamiPing -f -c 10 -s 492 294.217.300.20 PING 294.217.300.20 (294.217.300.20): 492 data bytes 11 packets transmitted, 10 packets received, 8% packet loss round-trip min/avg/max = 253.64/304.9/328.725 ms 568 rapide avec -f : MiamiPing -f -c 10 -s 568 294.217.300.20 PING 294.217.300.20 (294.217.300.20): 568 data bytes 12 packets transmitted, 10 packets received, 16% packet loss round-trip min/avg/max = 254.235/312.683/387.104 ms 1492 rapide avec -f : MiamiPing -f -c 10 -s 1492 294.217.300.20 PING 294.217.300.20 (294.217.300.20): 1492 data bytes 13 packets transmitted, 10 packets received, 23% packet loss round-trip min/avg/max = 440.244/570.651/671.445 ms 1492 normal sans -f : Une ligne de commande sans f permet d'avoir une plus grande description de la transmission des paquets mais aucun ne sera perdu car MiamiPing attend la réception avant d'envoyer un paquet de nouveau. MiamiPing -c 10 -s 1492 294.217.300.20 PING 294.217.300.20 (294.217.300.20): 1492 data bytes 1500 bytes from 294.217.300.20: icmp_seq=0 ttl=252 time=437.072 ms 1500 bytes from 294.217.300.20: icmp_seq=1 ttl=252 time=446.639 ms 1500 bytes from 294.217.300.20: icmp_seq=2 ttl=252 time=450.65 ms 1500 bytes from 294.217.300.20: icmp_seq=3 ttl=252 time=444.363 ms 1500 bytes from 294.217.300.20: icmp_seq=4 ttl=252 time=445.099 ms 1500 bytes from 294.217.300.20: icmp_seq=5 ttl=252 time=444.067 ms 1500 bytes from 294.217.300.20: icmp_seq=6 ttl=252 time=435.679 ms 1500 bytes from 294.217.300.20: icmp_seq=7 ttl=252 time=444.741 ms 1500 bytes from 294.217.300.20: icmp_seq=8 ttl=252 time=442.912 ms 1500 bytes from 294.217.300.20: icmp_seq=9 ttl=252 time=442.271 ms 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 435.679/443.349/450.65 ms 2.3 En résumé (pour l'exemple modem 56k à 45333) Nous pouvons observer deux choses : Plus le MTU est petit, plus le temps de réception des paquets est petit (296 rapide avec -f = 185 ms et 1492 rapide avec -f = 570 ms). Plus le MTU est petit, plus le nombre de paquets est envoyé rapidement,plus le nombre de paquets perdus est faible (296 rapide avec -f = 0 de perdu, et 1492 rapide avec -f = 3 de perdus). Que faire alors ? 1. Faites des essais avec MiamiPing -f -c xx -s xxxx xxx.xxx.xxx.xx avec différentes valeurs et plusieurs fois les mêmes valeurs jusqu'à trouver le bon MTU. Un bon MTU sera une commande -f lancée de nombreuses fois sans perte de paquets. 2. Faites les mêmes essais à d'autres périodes de la journée ou le Week-end pour valider votre valeur MTU trouvée. 3. Installez Miamigraph et GelBesPanel pour visualiser vos essais graphiquement et même en valeur instantanée avec GelBesPanel. Vous allez vous rendre compte graphiquement que plus le MTU est petit, plus la valeur moyenne de réception des données est grande. Vous constaterez que, avec une connexion à 45333 (6000 octets maxi avec les en-têtes TCP + IP) :
Le résultat pourra être un MTU à 296, 492 ou 568 pour un modem RTC et 1500 ou approchant pour un modem ADSL ou câble. Ce résultat sera valable pour votre installation avec votre modem, vos câbles de liaison jusqu'à votre ligne téléphonique et la qualité de votre ligne téléphonique. 4. Vérifiez vos résultats en utilisant des sites Internet comme ceux cités dans le chapitre suivant (ftpk ou sdv). Ceux-ci vous donneront des résultats sous forme graphique avec comparaison avec le RTC, ADSL ou le câble. Sites Internet intéressants Pour connaître son taux de download en mode compression ou non : bw.sdv.fr. Pour connaître son taux de download sans compression avec des infos sur l'adresse du premier routeur de chez vous : services.ftpk.net/speedtest/test. mire.ipadsl.net. Test complet mais pour les Etats-Unis (pour information) : pcpitstop.com/internet. Bien sûr, il en existe bien d'autres encore. Conclusion J'espère que cet article vous sera utile, d'abord général puis axé plutôt sur le côté pratique Amiga en RTC, avec des conseils complémentaires. Le but recherché est de donner une méthode Amiga pour contrôler et vérifier la valeur MTU utilisable avec un matériel Amiga et une localisation géographique en rapport avec son FAI. La valeur MTU miracle n'existe pas pour tous les cas (sauf en ADSL) mais ici, l'utilisateur arrivera à comprendre et à modifier sa valeur MTU vers une valeur presque idéale pour lui. |
